ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング
この本が対象にしているドキュメントというのはGCPとかKubernetesみたいなエンジニアが主に使うサービスやプロダクトの技術ドキュメントを指している。
この本を読んで最も感銘を受けたのはドキュメントを作成/運用していく過程はプロダクト開発を行うこととほとんど同じという点だ。
序盤から終盤まで一貫して述べられるのはユーザーのニーズをどうやったら満たせるのか？という徹底的なユーザー視点である。その観点はこのドキュメントは誰が読むのか？を定義するためのペルソナ作成やインタビューにつながるし、ドキュメントの見出しの付け方や文章構成全般にも至る。
作成したらそれで終わりではなく運用がどこまでも続いていくのもプロダクト開発と同じだ。新しい機能が追加されたらドキュメントの加筆が必要だし、機能が削除されたらドキュメントの方も削除しないといけない。ドキュメントもプロダクト同様に生き物なのだ。メンテナンスし続けなければ荒地になってしまう。
この本ではそうしたプロダクトの機能の一部としてのドキュメント作成についてのプロセス全般が取り上げられている。これを読むとドキュメントを作る仕事をしてる人は何をやっているのかがなんとなく見えてきてよかった。
ただこのツールを使ってどうこうみたいな具体的なテクニックのような話は多くないので別途他の本などをあたると良さそう。
ただし巻末にそれぞれのドキュメント作成運用過程で便利なツールの紹介はまとまっている
巻末にあるリソースというページにテクニカルライティングを学びたい人のためのGoogleが公開してるCourseなどが紹介されたりしてたからそれらを辿って学ぶのも良さそうに思った。それと日本語の文章術みたいなテクニックについては別途流儀があり、自分も昔読んだことのある理科系の作文技術などを読む必要はありそう。 あとこれはドキュメントの話に限らないけど良いなと思った話として、ドキュメントのアップデートはみんなでやろう！とすると進まなくなるから誰か一人けつもち役の責任者を立てるというのがあった。みんなにとって重要でみんなでやるべきことであっても、それがうまくいかない時に誰が悪いのかの責任を取らせられる状況を作っておかないと、なぁなぁになって重要なのに進まないといったことがおきがち。日常の仕事の中でも結構あるよな〜こういう状態、などと思ったりした。